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An important design decision that every OIS programmer must make is how much generality 
and modularity each program and each subsystem should have. Generality and modularity 
allow a specific piece of software to be used without modification for a long time. The 
simple approach to modularity is to use separate procedures for pieces of software that 
should be independent. If this is the only precaution that is taken, however, then it may still 
be necessary for the procedures that use a given procedure either directly or indirectly to be 
rewritten or recompiled when the procedure is modified, even if the purpose of the 
procedure has remained the same and the amount of information given to it by other 
procedures has remained the same. The most common kind of problem with this approach 
arises with the data that is passed between procedures. Usually the exact representation for a 
piece of data is determined by estimating the requirements and the frequency of the various 
operations on the data and then designing a representation on which all the operations can 
be performed and on which the most frequent operations can be performed quickly. This 
means that if a procedure is rewritten, the representation of the data used by the procedure 
may also change. Furthermore, two different procedures may very well use two different 
representations for the same kind of data. Any procedure that is written to be used by both 
of these procedures should be able to deal with both representations. 

Extreme independence between two bodies of software can be achieved if the data 
communicated between the pieces of software are created as objects and used as objects. In 
order for a procedure to be able to identify which object it is dealing with, the procedure 
has an object handle for the object. An object handle is basically a pointer to the object, but 
it also identifies the type of the object, i.e. the way in which the object is represented. The 
most important property of an object handle is that the size of the object handle is the same 
regardless of what type of object it refers to. Thus the object handle may be copied by 
software that is not dependent on the representation of the object itself. A major purpose of 
objects is to allow two pieces of software, e.g. procedures A and B, that actually interact in 
some way, i.e. procedure A calls procedure B, to be as independent of each other as possible. 
The interaction occurs when procedure B wishes to perform an operation on data, e.g. object 
X, that was created by procedure A. To isolate A from B, procedure B must invoke an 
operation on X that comes very close to performing the entire manipulation on X that is 
desired by B. If such an operation is not available, then two or more operations on X may 
be performed, but only by risking the amount of actual independence between A and B. As 
far as procedure B is concerned, this is a high-level operation on X whose exact 
implementation details are of no concern to B. Usually such operations can be described to 
people by describing the object that X is supposed to represent and then describing the 
operation as a meaningful operation on the abstract object that X represents. Thus procedure 
A must merely be able to pass an object to B on which a set of operations are defined that B 
considers to be high level operations. The details of the implementation are left to A, 
however, because A defines the data type of X. Whenever a new data type is defined, the 
programmer that creates the data type must specify what operations are defined on objects 
of that type and must provide the code that performs all of those operations. 



Objects in Mesa 

There is no doubt that Mesa does not encourage the use of runtime type determination. This 
does not mean that it is impossible, or even unusually inefficient, to create and use objects 
in Mesa, however. Mesa is designed with the philosophy that there is a great deal of code on 
a system that in fact uses only one representation for its data and that this code will run 
significantly faster if does not have to continually check the data type of its data. Mesa 
therefore suggests that even if source code is written so that it is independent of the 
representation of its data, when the code is compiled it should be made dependent upon the 
representation of its data. If a change is made later, the code can be recompiled to make use 
of the changed representation. There is a good deal of merit to this argument, but it should 
not be seen as an absolute position that objects are never needed at runtime. The problem 
becomes, then, how objects fit into the Mesa philosophy, rather than dwelling upon the 
limitations of the Mesa philosophy. 

The basic assumption of the Mesa philosophy is that although object-oriented programming 
can achieve a great deal of independence between different pieces of software, it is often 
possible to skimp on the implementation of the object-oriented approach in order to achieve 
greater speed of execution. Often, the only penalty for this skimping on the runtime 
implementation of objects is the need to recompile some extra pieces of software when a 
change is made. It must be left to the programmer to decide in each case, however, whether 
this extra compilation is acceptable or not, especially since there are some cases where the 
ability for an object handle to point to different types of objects at different times is 
essential. Even if the decision is made to increase the low-level runtime overhead in order to 
achieve certain degrees of runtime generality, however, there are still varying degrees of 
generality that can be achieved with varying degrees of low-level overhead. The difference 
in generality and in overhead is achieved by using different formats of object handle and 
different conventions for using object handles. Thus we see that the Humus design of object 
handle achieves a great deal of generality, but involves what many people consider to be too 
much low-level overhead and indeed it is not clear that Mesa can be made to follow the 
conventions for the use of Humus object handles properly. On the other hand, it is possible 
to define a kind of object handle in Mesa that allows a range of different representations of 
objects to be used without causing the overhead used by Humus object handles. The Mesa 
philosophy that the compiler should sacrifice runtime generality for runtime speed, 
especially if source-code generality is not sacrificed, leads to the conclusion that many 
different kinds of object handles should exist. 

It becomes even more clear that it will be necessary to have several different formats of 
object handle in DO Mesa because of the nature of the address space on the DO. There are 
MDS pointers which are extremely efficient but cannot point outside of a single MDS. There 
are 24 and 32 bit pointers that point within virtual memory but do not point within files. 
There are FilelDs that point at files. There can be innumerable kinds of pointers to objects 
within files, since it is necessary for software to interpret such addresses regardless of what 
representation is chosen. 

Once the decision is made that there must be several different types of object handles, then 
the Mesa philosophy becomes a sufficient reason to insist that programmers be able to create 
their own kinds of object handles rather than using one of 20 flavors of object handle that 
have been designed by system programmers. 

When a program A uses a piece of data X, but wishes to be independent of the 
representation of X, then there are two pieces of software that should be independent: 
program A that invokes several operations on X, and the definitions of those operations that 
are procedures that were written by the programmer that defined the type of X. If a system 
has only one format of object handle, then it is acceptable for either or both of these pieces 
of software to be dependent upon the format of object handle that is being used, but if there 
are several different possible formats of object handle, then a change in the type of object 
handle should not require program A or much of the definitions of the operations on X to 



be rewritten (it may be necessary for program A to be recompiled, however). 

All of the constraints listed above can be achieved in Mesa 4.0 without causing any runtime 
overhead to separate the choice of object handle format from both the users of the objects 
and the implementors of specific data types. The rest of this memo presents such a style of 
using objects in Mesa and explores the possibilities of the proposed style. There are three 
programmers that must be considered: the user of an object, the definer of a data type, and 
the definer of a format of object handle. In order for these three programmers to be 
separated from each other, two definitions files are necessary (see Figure 1). 

K The User of an Object 

The user of an object merely has to invoke operations on an object and declare variables 
that use the specific format of object handle. The user of an object will have a definitions 
file that provides a declaration for the type of the object handle, e.g. WidgetHandle. The 
user of the object can then declare variables to be of type WidgetHandle and then obtain 
such an object handle from an appropriate piece of software. The declaration of 
WidgetHandle should specify that all of the fields are PRIVATE so that the user of the 
object will not access any of the fields in the object handle explicitly. This same definitions 
file will contain declarations for the generic procedures that perform the legal operations on 
objects with that type of object handle. These procedures are generic because they operate on 
any type of Widget. By convention, the first argument to a procedure that performs an 
operation on an object is the object handle of the object on which the operation is to be 
performed. This is merely a notational convenience so people will be able to tell quickly 
which object is being operated on. The user of an object handle invokes an operation on an 
object by calling the generic procedure that implements that operation: 

val <- Append [widget, anotherwidget]; 

This method of invoking operations on objects in Mesa has several advantages: 

1) it can be used regardless of the representation of the object handle without 
causing runtime overhead over any other method of invoking the operation, and 

2) it allows Mesa type-checking to protect the user against mistakenly invoking the 
wrong procedure on the set of arguments that have been supplied. 

2. The Definer of a Data Type 

The programmer that creates a data type must provide a declaration of the type of the 
object, must implement the operations on this particular type of object, and must provide 
procedures that create objects of this type. The definer of the data type must provide a 
definitions file that makes these interfaces available to client code that is dependent upon 
the type of object being manipulated. Note that any client code that creates an object must 
specify the representation of object to be created. The definer of the data type defines a 
procedure for each operation on the object (e.g. Append) whose calling sequence is the same 
as the generic procedure except that instead of a general object handle as the first argument 
(WidgetHandle), the first argument can only be of a specific type (HelpedWidgetHandle). It 
is the responsibility of the generic procedure to invoke this specific procedure on objects of 
the appropriate type. Note that in the case of binary operations, such as Append, only one 
of the arguments is guaranteed to be of a specific type by the generic procedure. 

3. The Definer of a Format of Object Handle 

The definer of a format of object handle must provide the definitions file that is used by 
the user of the object. The generic procedures must also be provided, but these procedures 
need only call the appropriate procedures created by the definers of specific data types. If 



the generic procedures are simple enough, they can be Inline procedures that Mesa expands 
to inline code instead of performing the procedure call to the generic procedure. It is this 
possibility of using inline procedures for generic procedures that allows us to consider this 
proposal as a serious alternative to the Humus approach of using objects in Mesa. 

Harsh Realities 

The above description of how we would like to organize the software that deals with objects 
ignores a few harsh realities of Mesa. The Mesa supplied in Appendices B~D show a variety 
of techniques that deal with these harsh realities. Current Mesa seems to prevent the 
declaration of a skeleton variant record in one definitions file (e.g. Widget in Figure 1) that 
is expanded to include more variants in a different definitions file (e.g. HelpedWidget). If 
we insist on this division (as Humus does), it seems that it is necessary to use LOOPHOLES 
in many places that effectively robs the Mesa of much of its type-checking. The necessary 
LOOPHOLES can be seen in the use of TableHandles in Appendix B. Humus makes these 
LOOPHOLES less obvious by using some procedures that only do a LOOPHOLE. Such 
procedures would even be efficient in Mesa 4.0 since they would be Inline procedures. 

Variant Records 

If we would prefer to have LOOPHOLE-free Mesa, however, then we can make use of 
variant records. The main difficulty with this approach is that there must be a single 
definitions file that contains the declarations of all of the variants in the variant record. 
This means that if a new data type is added, a new variant must be added and thus all of the 
software that uses this kind of object handle must be recompiled. In some cases, such a 
limitation on runtime generality is acceptable. For one thing, it is probable that whenever a 
new software release is made, most or all of the software will have been recompiled for the 
release. Secondly, there are many times when a programmer has a good idea of the range of 
data types that will be necessary, so declarations can be made for all of the data types before 
the software for each data type is written. As we will see later, this kind of pre-planning is 
even easier if prototyping is done in Smalltalk first. 

If the, object handle designer decides to use variant records, he has a choice of where the 
variant record is placed. Either the object handle or the object itself could be declared to be 
a variant record. In Appendix B, we see that ElementHandles are variant records. In 
Appendix C, however, Tables rather than TableHandles are variant records. The purpose of 
an object handle is to provide a small, mobile handle for the object. Thus programs copy 
object handles without knowing what type of object is referred to. It is often desirable to 
make the object handle be simply a POINTER TO the object, which is a variant record. If, 
however, it is inconvenient to provide type information in the object, then it may be better 
to make the object handle be a variant record that always contains a POINTER TO the 
object. The type of the variant specifies the type of object that is pointed at. 

Ordinary Mesa is a Special Case 

The most interesting aspect of the approach to objects suggested here is that ordinary high 
quality Mesa falls out of the style in the special case where the definer of the object handle 
decides that there is only one possible representation for the object. In this case, the Specific 
Type Definitions File (see Figure 1) is used as the General Definitions File as well. In the 
example in Figure 1, however, the type of object handle would probably be called 
"WidgetHandle" rather than "HelpedWidgetHandle". Although the single definitions file 
appears to be the Specific Type Definitions File, this is mainly because it contains the 
declaration of MakeWidget. If, at a later time, the decision to have only one kind of Widget 
is changed, then this single definitions file becomes the General Definitions File and a new 
definitions file is created for HelpedWidgets. The client software must be recompiled when 
this change is made since the declaration of WidgetHandle would be changed. The code that 
implements HelpedWidgets will be modified to use the new type "HelpedWidgetHandle" to 
point to widgets that are known to be helpedwidgets. In addition, there will be other 



modifications that must be made to this code to make use of the fact that either the 
widgethandles or the widgets will have type information stored in them. 

Converting Smalltalk to Mesa 

There has been considerable interest in SD in using Smalltalk as a tool for constructing 
prototypes. Since Smalltalk is so easy to modify, this would allow many different user 
interface possibilities to be prototyped rapidly. At some point, the Smalltalk code would be 
converted into Mesa. Some people have been concerned that Smalltalk programmers would 
write programs that depended too much on the sophisticated features of Smalltalk to be 
converted into efficient Mesa. Fortunately, the essential object-oriented programming 
encouraged by Smalltalk can be mapped into acceptable Mesa. There are only two 
fundamental assumptions made in Mesa that need not be accepted by the Smalltalk 
programmer: 

1) once an object has been allocated in virtual memory, it is not necessary to move 
the object in memory in order to fight fragmentation of storage, and 

2) it is acceptable to have many different kinds of object handles since there is no 
software that is in fact used by all parts of the system and thus needs a single kind 
of object handle that can refer to any object in the system. 

It is possible that these assumptions could cause some difficulty when converting Smalltalk 
programs to Mesa, but this would imply that these assumptions are invalid for the 
applications we are interested in writing software for. If we take the point of view that these 
assumptions are in fact valid for our applications, then the Smalltalk code that prototypes 
our applications should not run into these problems. 

Thus the Mesa programmer should start from the position that storage compaction is 
unnecessary. This is an important point of disagreement between myself and the Humus 
approach, in which they created a storage compactor. 1 disagree with the Humus approach on 
this point because significant changes need to be made to Mesa in order to allow a storage 
compactor utility that can be invoked at any time. If storage compaction is needed, it can 
run at a time when no temporary variables are pointing into the middle of the area of 
storage that is being compacted. Even a compactor of this form should only be written when 
it becomes clear that it is necessary. If this approach to compaction is not adequate, it is a 
major indictment of Mesa and the Algol-68, PL/1 family of languages to which Mesa 
belongs. It is interesting to note that none of the Smalltalks before Fastalk had compaction 
of high speed memory, and this did not seem to be a significant problem. Paged Smalltalk 
did not have compaction, either, but again, there were not significant problems with 
fragmentation of storage. Paged Smalltalk suffered much more from the lack of a compactor 
that would place related objects together, rather than just a compactor that eliminated 
fragmentation of storage. Note that Humus also has different kinds of object handles and so 
it, also, is dependent upon the second assumption being valid. 

One of the advantages of prototyping in Smalltalk is that it is very easy to write very general 
Smalltalk code. As a result, it is very easy to make changes to Smalltalk code. In particular, it 
is seldom necessary to make a change to Smalltalk code in order to provide generality in the 
code. When Smalltalk code is converted to Mesa code, however, it is necessary for the 
programmer to determine how much of the runtime generality is, in fact, used and to write 
Mesa code that has only as much runtime generality as is needed. Appendix A shows the 
Smalltalk sort routine and appendices B~D show three different implementations of the sort 
routine in Mesa. The first piece of generality that exists in Smalltalk but was eliminated 
from all three Mesa implementations is reference counting. It is usually possible to eliminate 
reference counting from Smalltalk code. In the few cases where it is not possible, however, 
reference counts can be supplied by the Mesa programmer and can be incremented and 
decremented explicitly. The frequency of incrementing and decrementing the reference 
counts can be drastically reduced from their frequency in Smalltalk when they are done 



explicitly unless the reference counting feature of Smalltalk is being abused. 

The second piece of generality that was eliminated from the Mesa implementations of the 
sort routine was the possibility of using other representations of numbers besides integers, 
such as floating point, to index the table that is being sorted. Since this sort routine looks 
like it would work well on very large tables, however, I allowed the possibility that there 
might be more than 65000 elements in the table, so the indices into the table to be sorted are 
double precision. 

The first implementation of the sort routine in Mesa (see Appendix B) uses two different 
types of object handles: TableHandles for the table to be sorted and EtementHandles for the 
elements of the table. Two different formats of object handle are used in these two cases. 
TableHandles use the basic Humus approach of making a table be essentially a variant 
record in which the tag points to an array of procedures. This must be done without help 
from Mesa, however, so it does not use Mesa variant records and it does use LOOPHOLES 
in several embarassing places. ElementHandles, on the other hand, use Mesa variant records 
and so do not use any LOOPHOLES. Note that both approaches require initialization code 
that constructs the arrays of procedures that allow the generic operations to invoke the 
proper procedures. Also note that the code in testsort accesses directly into the table because 
testsort actually creates a specific kind of table and so knows what its representation is. 

1 was disturbed by the large number of kinds of object handles in Appendix B, so I 
restructured the operations on Tables so that none would return a reference to an element of 
the table. I replaced the Index and Swap operations on tables and the Compare operation on 
elements by an IfCompareSwap operation on tables. Appendix C contains the Mesa that 
resulted from this modification to the structure of the sort program. This example points 
out that Smalltalk programmers should make an attempt to structure their messages so that a 
minimum number of different kinds of object handles that require runtime generality will 
be needed. Another change that was made from Appendix B to Appendix C was to use Mesa 
variant records for Tables. No LOOPHOLES appear in the code of Appendix C. 

Finally, Appendix D was created to show what the Mesa would look like if we decided that 
no runtime generality was needed for the sort routine. Only one type of table can be sorted 
by the code in Appendix D. Since this type of table must fit in virtual memory, I also 
eliminated the generality of having double precision indices into the table. 

Conclusion 

The appendices do not represent recommendations for how the sort routine should be 
implemented in Janus. The appendices are merely intended to show several different ways of 
implementing Smalltalk programs in Mesa in the rare cases when a Smalltalk program 
actually makes use of the possibility of operating on several different representations of the 
same object. 

This memo presents a set of ideas that I think need to be thought about and discussed. 
Topics that will be covered in later memos are: 

1) whether files should be objects, 

2) how to translate Smalltalk subclasses into Mesa, and . 

3) how Mesa could be improved so that the considerations in this memo listed under 
"harsh realities" would not exist. 
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(for creation of HelpedWidgets) 



General Definitions File 



WidgetHandle: TYPE = PRIVATE POINTER TO Widget; 
Widget: TYPE = PRIVATE RECORD [dummy: CARDINAL]; 

Append: PUBLIC PROCEDURE [first: WidgetHandle, 

second: WidgetHandle] RETURNS [val: WidgetHandle]; 
Reduce: PUBLIC PROCEDURE [widget: WidgetHandle, 

by: CARDINAL]; 
Invert: PUBLIC PROCEDURE [widget: WidgetHandle]; 
Find: PUBLIC PROCEDURE [widget: WidgetHandle, 

get: CARDINAL] RETURNS [loc: CARDINAL]; 



Definer of WidgetHandle 



Specific Type Definitions File 



HelpedWidgetHandle: TYPE = PRIVATE POINTER TO HelpedWidget; 
HelpedWidget: TYPE = PRIVATE RECORD [count: CARDINAL, 

helper: HelperHandle, state: HWState]; 
HWState: TYPE = (nil, initialized, helped, complete); 

MakeHelpedWidget: PUBLIC PROCEDURE [helper: HelperHandle] 

RETURNS [val: HelpedWidgetHandle]; 
Append: PUBLIC PROCEDURE [first: HelpedWidgetHandle, 

second: WidgeHandle] RETURNS [val: WidgetHandle]; 
Reduce: PUBLIC PROCEDURE [widget: HelpedWidgetHandle, 

by: CARDINAL]; 
Invert: PUBLIC PROCEDURE [widget: HelpedWidgetHandle]; 
Find: PUBLIC PROCEDURE [widget: HelpedWidgetHandle, 
get: CARDINAL] RETURNS [loc: CARDINAL]; 



Definer of HelpedWidgets 
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"Array 11 
Class new title: 'Array 1 ; 
fields: "; 
asFollowsS 

Array is an abstract class in the sense that it has no state, and instantiation is consequently not 
meaningful. However it defines the default message set inherited by its subclasses, notably String, 
Vector, and UniqueString. Notice that subscripting is not done here, except to handle the 
exceptional cases such as subscripting by other types as in a* (1 to: 3 J. 

Reading and Writing 

• X 

[tx subscripts: self] 
' x f- val 

[fix subscripts: self *- val] 
= arg | x 

[self length * arg length=> [ITfalse] 

for? x to: self length doS 

[(self -x) = (arg"x):» [] tffalse] 

ttrue] 
all «~ val | i 

[forS i to: self length doS 
[self "i «- val]] 
last 

Itself "self length] 
last «• val 

[ITself 'self length 4- val] 
length [user notify: 'message not understood.*] 

Copying and Altering 

+ a^g [ITself co neat: arg] 
concat: arg | x 

[x «- self species new: self length + arg length. 

self copyto: x. 

arg copyto: (Stream new of: x from: self lengths 1 to: x length). 

fix] 
copj- '• ~- 

[frself copyto: (self species new; self length)] 
copy: a to: b [fr(self "(a to: b)) copy] 
copyto: t | i s me 

[s *- t asStream. 

me «- self asStream. 

forS i to: self length doS "general code wont stop at false" 

[s next *- me next] 

delete: obj | s each 

[s «- (self species new: self length) asStream. 

foro each from: self doS 

[obj=each=>[] s next*- each] 

ft s contents] 
grow 

[ftself copyto: (self species new: (4 max: self length*2))] 
growby: n 

[ftself copyto: (self species new: self lengthen)] 
replace: a to: b by: s | x xs 

[x *- self species new: self lengtli+s length -(1+b-a). 

xs «- x asStream. 

self*(l to: a-1) copyto: xs. 

s copyto: xs. 

self *(b+l to: self length) copyto: xs. 

ftx] 

swap: i with: j j"t "~~ 

[t <~ self *i. self'i *- self'j. self*j «- t] 

Sorting and Searching 

find: x ( i 

[forS i to: self length doS 




A 2 



[self- i=x^ [ti]]. 

to] 

findnon: x | i 

[forS i to: self length do§ 
[seiri*x=>[ti]]. 

to] 

TleiS* X 

[tO*(self find: x)] . 
insertNonDescending: x | a c lo mid hi "self is assumed to be sorted" 

c «- (a «- self species new: (hi «- self length + (lo 4- 1))) asStream. 
whileS lo < hidoS [self "(mid«-lo+hi/2) > Xr> [hi 4- mid] lo 4- mid+1]. 
self*(l to: hi-1) copyto: c. c next 4- x. self '(hi to: self length) copyto: c. 
ta 

3 
insertSorted: x | a c lo mid hi "self is assumed to be sorted" 

[c 4- (a 4- self species new: (hi 4- self length + (lo 4- 1))) asStream. 

while o lo < hi do§ "binary search" 

[self "(mid^lo+hi/2) > x=>[hi 4- mid] lo 4- mid+1]. 

self *(1 to: hi-1) copyto: c. c next 4- x. self "(hi to: self length) copyto: c. 

ta] 
permutationToSort 

{J* Return a Vector, permutation, such that self" permutation is sorted nondescending. Do not 
alter self." 

t((self *((1 to: self length) copy)) sort: 1 to: self length) map,] 
promote: t | n 

[n 4- self find: t, n=0=> [] 

self "(n to: 2 by: "1) 4- self *(n-l to: 1 by: "1). 

selfl«-t] 
reverse 

[tSubstring new data: self ma p: (self length to: 1 by: ~1)] 
sort 



[" Permute my elements so they are sorted nondescending. Note: if I am a substring, only my 
map will be permuted. In certain situations, this may not be what you expect." 

self sort: 1 to: self length.] 
sort: i to: j |,di dij dj tt ij k 1 n 

["Sort elements i through j of self to be nondescending," 

"The prefix d means the data. at." } 

Cn«*j+l-i)^l=> I" Nothing to sort."] 
"Sort di.dj." 
di 4- self "i. dj 4- 'self *j. 

[di>dj^> [self swap: i with: j. tt<-di. di4-dj. dj«-tt]]. 
n=2=> ["They are the only two elements"'} 
ij 4- (i*j) Ishift: ~1. "ij is the midpoint of i and j." 
"Sort di,dij,dj. Make dij be their median." 
dij 4- self *ij. 

[di>dijr> [self swap: i with: ij. dij*-di] dj<dij=> [self swap: j with: ij. dij<-dj]]. 
n=3^ ["They are the only three elements."'} 

"Find h>i and IKj such that dk,dij,dl are in reverse order. Swap h and I. Repeat this procedure 
until j and h pass each other." 
k «- i. 1 *- j. 
whileS 

whileS self '(14-1-1) > dij doS []. 
whileS self '(k4-k+l) < dij doo []. 
k^l 

D 3 

doS 

[self swap: k with: 1]. 
"Now l(h (either 1 or 2 less J, and di through dl are all less than dh through dj. Sort tliose two 
segments." 

self sort: i to: 1. 
self sort: k to: j.] 



Mapping 

asStream 

[tStream new of: self] 
subscripts: x "subarrays" 

[tSubstring new data: x map: self] 



— File: testsort.mesa Last edited: November 4, 1977 5:49 PM By: Peter Bishop 

DIRECTORY 

lODefs: from "iodefs", 
SystemDefs: from "systemdefs", 
StringDefs: from "stringdefs", 
MyTableDefs: from "mytabledefs", 
SortDefs: from "sortdefs"; 

testsort.PROGRAM 

imports SortDefs, lODefs, MyTableDefs, SystemDefs, StringDefs = 
begin open lODefs, SystemDefs, StringDefs, SortDefs; 

—This program merely tests the sort routine. It allows the user to type in a table to be sorted, 
sorts the table, and prints out and frees the storage for the sorted table. 

size, i: cardinal; 

p: pointer TO MyTableDefs.Entry; 

name: string = " "; 

tab: MyTabieDefs.MyTableHandle; 

—testsort is the control program for the configuration, so initialize the sort routine. 
start SortProg; 

START MyTableDefs.TableProg; 

do — infinite loop containing a stop allows the program to be restarted. 

WriteString ["Enter size of table: "]; 

size «- ReadDecimal []; 

WriteLine [""]; 

tab <- MyTabteDefs.MakeMyTable [size]; 

FOR i in [L.size] do --fill in the entries in the table from the keyboard. 

WriteString ["name: "]; 

ReadiD [name]; 

p *• @tab.t[i]; 
^p.name «- AliocateHeapString[name.length]; 

p.name.length «- 0; 

AppendString[p.name, name]; 

WriteString [" value: "]; 

p.value «- ReadDecimal []; 

WriteLine [""]; 

endloop; 

WriteLine ["Sorting"]; 

Sort[LOOPHOLE[tab]]; —use the sort routine. 

~ A LOOPHOLE is needed at this point because tab is a specific kind of table, but Sort 
takes a general kind of table and because Mesa is not aware of the relationship between 
these two types. 

for i in [L.size] do —type out the sorted table and free the storage. 

p <- @tab.t[i]; 

WriteString[p.name]; 

FreeHeapString[p.name]; 

WriteString[" "]; 

WriteDecimal[p.value]; 

WriteLine[""]; 

endloop; 
FreeHeapNode[tab]; 
stop; 
endloop; 
end. 
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~ File: SortDefs.mesa Last edited: November 10, 1977 11:34 AM By: Peter Bishop 

DIRECTORY 

DoubleDefs: from "doubledefs"; 

SortDefs: definitions = 
begin open DoubleDefs; 

SortProg: program; 

TableHandle: type = pointer to Table; 
Sort: procedure [table: TableHandle]; 
Index: procedure [table: TableHandle, subscript: LongCARDINAL] 

returns [element: ElementHandle]; 
Swap: procedure [table: TableHandle, first: LongCARDINAL, 

second: LongCARDINAL]; 
Range: procedure [table: TableHandle] 

returns [low: LongCARDINAL, high: LongCARDINAL]; 
SubscriptOutOfBounds: error; 

ElementHandle: TYPE s private record [ 
var: select type: ElementType from 
string => [element: string], 
integer => [element: integer], 
endcase]; 
ElementType: type = [string, integer); 
SetElementTypeArray: procedure [ 
type: ElementType, 

compproc: procedure [first: ElementHandle, second: ElementHandle] 
returns [comp: Comparison]]; 
Compare: procedure [first: ElementHandle, second: ElementHandle] 
returns [comp: Comparison]; 

Table: private type = record [ 

type: pointer to TabieProcedures, 
tptr: pointer to unspecified]; 
TabieProcedures: private type = record [ 

Index: procedure [ TableHandle, LongCARDINAL] 

returns [ElementHandle], 
Swap: procedure [ TableHandle, LongCARDINAL, LongCARDINAL], 
Range: procedure [TableHandle] 

returns [LongCARDINAL, LongCARDINAL]]; 
end. 
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— File: Sort.mesa Last edited: November 4, 1977 2:32 PM By: Peter Bishop 

DIRECTORY 

DoubleDefs: from "doubledefs", 
SortDefs: from "sortdefs"; 

SortProg: program imports DoubleDefs 

exports SortDefs 

shares SortDefs = 
begin open DoubleDefs, SortDefs; 

Longl: LongCARDINAL = [highbits.O, lowbits:1]; 
Long2: LongCARDINAL = [highbits.O, lowbits:2]; 
Long3: LongCARDINAL = [highbits:0, lowbits:3]; 

Sort: public procedure [table: TableHandle ] ~ 

BEGIN 

x,y: LongCARDINAL; 
[x, y] <- Range [table]; 
SortRange[table, x, y]; 
end; 

SortRange: procedure [ 

table: TableHandle, i: LongCARDINAL, j: LongCARDINAL] = 

BEGIN 

n, ij, I, k: LongCARDINAL; 
di, dj, dij, tt: ElementHandle; 

—Sort elements i through j of table to be nondescending. 

--The prefix d means the data at. 

—The basic technique is to choose three elements from table 

—at "random" (first, last, middle), sort these three elements, 

—choose the middle element and then divide table into two parts, 

—the part all of whose elements are less than this middle value, 

—and the other part having only elements larger than the middle value. 

—SortRange is then called recursively on these two portions of the table, 

n <- DSub [Dine [j], i]; 

if n.highbits=0 AND n.lowbits< = 1 then return; —Nothing to sort. 

di «- Index [table, i]; 

dj «- Index [table, j]; 

—Sort di, dj. 
if Compare [di, dj] = greater then 

begin 

Swap [table, i, j]; 

tt <- di; 

di <- dj; 

dj <- tt; 

end; 
IF n = Long2 then return; —There are only two elements. 

[ij, ] <- DDivide [DAdd [ i, j], Long2]; --ij is the midpoint of i and j. 

dij <- Index [table, ij]; 

—Sort di, dij, dj so they are in nondescending order. 

—After this, we will only need to have dij valid - di or dj may be invalid. 

if Compare [di, dij] = greater then 

begin —Now we know that dij<di<=dj, so swap di and dij. 

Swap [table, i, ij]; 
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dij «- di; --we are not swapping di and dij properly 
—because di need not remain valid. 

END 

else if Compare [dj, dij] = less then 

begin --Now we know that di<=dj<dij, so swap dj and dij. 

Swap [table, j, ij];. 

dij <~ dj; --we are not swapping dj and dij properly 
—because dj need not remain valid. 

end; 
if n = Long3 then return; --di, dij, and dj are the only three elements. 
k *- i; 

I <- j; 

—Find k>i and Kj such that dk, dij, dl are in reverse order. Swap k and I. 

—Repeat until k and I pass each other, at which point k and I are approximately equal and 
specify the dividing line in the table between the elements that are less than or equal to 
dij and those that are greater than or equal to dij. SortRange is then called recursively on 
these two portions of the table. 

DO 

while Compare [Index [table, (l<~DSub [I, Longl])], dij] >= equal 

DO endloop; --Find I such that dKdij. 
while Compare [Index [table, (k <- Dine [k])], dij] <= equal 

do endloop; —Find k such that dij<dk. 
if DCompare [k, I] = greater then exit; —Do loop while k<=l. 
Swap [table, k, I]; — k will never equal I because dKdij <dk. 
endloop; 
—Now \<k and di through dl are less than or equal to dij while dk through dj are all greater 
than or equal to dij. 1+1 may be less than k, but only if the elements between dl and dk are 
all equal to dij. Fortunately, all elements equal to dij will cluster at exactly this point in the 
table anyway in one of three ways: 

— 1)l+1<k and the elements between are equal to dij. 

—2) elements equal to dij within di through dl are larger than any other elements in that 

range and so will be placed at I. 
—3) elements equal to dij within dk through dj are less than any other elements in that 
: - range and so will be placed at k. 

—Thus it is alright for elements equal to dij to be sprinkled all over the table at this point 

SortRange [table, i, I]; 
SortRange [table, k, j]; 

return; 
end; 

SubscriptOutOfBounds: public error = code; 

Index: public procedure [table: TableHandle, subscript: LongCARDINAL] 
returns [element: ElementHandle] = 
begin 

element «- table.type.lndex [table, subscript]; 
end; 

Range: public procedure [table: TableHandle] 

returns [low: LongCARDINAL, high: LongCARDINAL] = 

BEGIN 

[low, high] <- table.type.Range [table]; 
end; 

Swap: public procedure [ 

table: TableHandle, first: LongCARDINAL, second: LongCARDINAL] = 
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BEGIN 

table/type. Swap[table, first, second]; 
end; 

Compare: public procedure [first: ElementHandle, second: ElementHandle] 
returns [comp: Comparison] = 

BEGIN 

comp «- Comparearray [firsUype].proc [first, second]; 
end; 

--This next procedure is used to initialize the array that contains the specific Compare 

procedures for specific data types. This procedure is used mainly during initialization, but 
may be called at any time to define an undefined ElementType. 
SetEIementTypeArray: public procedure [ 
type:ElementType, 

compproc: procedure [first: ElementHandle, second: ElementHandle] 
returns [comp: Comparison]] = 

BEGIN 

if Comparearray[type].set then error duplicateTypeDefinition[]; 
Comparearray [type].proc <- compproc; 
Comparearray [type]. set <- true; 
end; 

Comparearray: array ElementType of record [ 
set: boolean, 
proc: procedure [ElementHandle, ElementHandle] returns [Comparison]]; 

duplicateTypeDefinition: error; 

t: ElementType; 

for t in ElementType DO --The Comparearray must be initialized to nil. 
Comparearray[t].set «- false; 
endloop; . 

END. 
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— File: mytabledefs.mesa Last edited: November 4, 1977 5:29 PM By: Poter Bishop 

DIRECTORY 

SortDefs: from "sortdefs"; 

MyTab!eDefs:DEFiNiTiONS 

shares SortDefs = 
begin OPEN SortDefs; 

MyTableHandle: type = pointer to MyTable; 
MyTable: typ$ = record[ 

type: pointer to TableProcedures, 
size: cardinal, 
t: array [1..1) OF Entry]; 
Entry: type = RECORD[name: string, value: integer]; 
MyElement: type = string ElementHandle; 

MakeJVIyTable: procedure [size: cardinal] returns [val: MyTableHandle]; 

—This procedure constructs tables of this specific type. Procedures of this form are used 
to create objects rather than defining ••initialize" operations on objects. 

TableProg: program; 

end. 
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— File: table.mesa Last edited: November 10, 1977 11:38 AM By: Peter Bishop 

DIRECTORY 

SortDefs: from "sortdefs", 
SystemDefs: from "systemdefs", 
MyTableDefs: from "mytabledefs", 
DoubteDefs: from "doubledefs"; 

TableProg: program imports SortDefs, SystemDefs 

exports MyTableDefs 

shares SortDefs = 
begin open SortDefs, DoubleDefs, MyTableDefs; 

MyTableProcs: TableProcedures; 

MakeMyTable: public procedure [size: cardinal] 
returns [val: MyTableHandle] = 

BEGIN 

val «- SystemDefs.AllocateHeapNode[size*stZE[Entry] + siZE[MyTable]]; 
val.type <- ©MyTableProcs; 
val.size «- size; 
end; 

Index: procedure [table: MyTableHandle, subscript: LongCARDINAL] 
returns [val: MyElement] = 
begin 

p: pointer to Entry; 
i: cardinal; 

i«- Shorten[table.size, subscript]; 
p «- @table.t[i]; 
val *- [string [p. name]]; 
end; 

Swap:- procedure [table: MyTableHandle, first, second: LongCARDINAL] = 
begin 

f,s: pointer to Entry; 
temp:Entry; 

f <- @table.t[Shorten[table.size, first]]; 
s *• @table.t[Shorten[table.size, second]]; 

temp <- ft; — Swap first and second. 
ft *- st; 

st *- temp; 
end; 

Range: procedure [table: MyTableHandle] 

returns [low, high: LongCARDINAL] = 
begin 

low.highbits «- high.highbits <- 0; 
low.lowbits <- 1; 
high.lowbits «- table.size; 
end; 

Shorten: private procedure [size: cardinal, subscript: LongCARDINAL] 
returns [i: cardinal] = 
begin 



--This procedure checks subscripts to make sure that they are within the table and converts 
them to single precision. 

i *- subscript.lowbits; 

if subscript. highbits # OR i > size OR i = then 

error SubscriptOutOfBounds []; 
end; 

Compare: procedure [first, second: ElementHandle] 
returns [comp: Comparison] = 
begin 

I, i: cardinal; 

f, s: string ElementHandle; 
with x: first select from 

string => f «- x; 

endcase => error; 
with x: second select from 

string => s «- x; 

endcase => error; 
I <- MiN[f.element.length, s.element. length]; 
comp «- equal; 
for i in [O.J) do 

if f.elementp] # s.element[i] then 

BEGIN 

comp *- (if f.element[i] > s.elementp] then greater else less); 
exit; 
end; 
endloop; 
if comp = equal then 

if f.element. length > I then comp «- greater 
else if s.element. length > I then comp «- less; 
end; 

SetE!ementTypeArray[type:. string, compproc: Compare]; 

—This procedure call initializes the Comparearray that allows the generic Compare procedure 
to invoke this Compare procedure on this type of Element. 

MyTableProcs.lndex *- loophole [Index]; 
MyTabieProcs.Range «- loophole [Range]; 
MyTableProcs.Swap <- loophole [Swap]; 

—These statements initialize the array of procedures that define the operations on tables. The 

generic operations invoke these operations because Tables contain a pointer to this array 

of procedures. 

END. 



— File: testsort2.mesa Last edited: November 8, 1977 11:26 AM By: Peter Bishop 

DIRECTORY 

lODefs: from "iodefs", 
SystemDefs: from "systemdefs", 
StringDefs: from "stringdefs", 
SortDefs: from "sortdefs2"; 

tes tsort 2 : program 

imports SortDefs, lODefs, SystemDefs, StringDefs 

shares SortDefs = 
begin open lODefs, SystemDefs, StringDefs, SortDefs; 

size, i: cardinal; 

p: pointer to StringlntEntry; 

name: string = " "; 

tab: pointer to stringlnt Table; 

start SortProg; 

start StringlntTableProg; 

DO 

WriteString ["Enter size of table: "]; 

size «- ReadDecimal []; 

WriteLine [""]; 

tab «- MakeMyTable [size]; 

for i in [L.size] do 

WriteString ["name: "]; 

ReadID [name]; 

p <- @tab.t[i]; 

p.name <- AllocateHeapString[name.length]; 

p.name.length ♦- 0; 

AppendString[p.name, name]; 
: WriteString [" value: "]; 

p.value <- ReadDecimat []; 

WriteLine [""]; 

endloop; 

—Note that in this implementation, LOOPHOLES are not needed either to invoke the Sort 
procedure or to modify the fields of a table when the code is sure it is dealing with a 
specific type of object. 

WriteLine ["Sorting"]; 
Sort[tab]; 

FOR i in [L.size] do 

p + @tab.t[i]; 

WriteString[p.name]; 

FreeHeapString[p.name] ; 

WriteString[" "]; 

WriteDecimal[p.value]; 

WriteLine[""]; 

endloop; 
FreeHeapNode[tab]; 
stop; 
endloop; 

end. 
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— File: SortDefs2.mesa Last edited: November 8, 1977 10:58 AM By: Peter Bishop 

DIRECTORY 

DoubleDefs: from "doubledefs"; 

SortDefs: definitions = 
begin open DoubleDefs; 

SortProg: program; 

--This sort procedure is written in terms of the IfCompareSwap operation on tables, which 
does not require the sort routine to have ElementHandles, so only one type of object handle 
is declared in this definitions file: TableHandle. 

TableHandle: type = pointer to Table; 
Sort: procedure [table: TableHandle]; 
—The IfCompareSwap procedure compares the first element in the table to the second 

element in the table and if the condition specified by CompareOp is satisfied, the elements 
are swapped. In any case the procedure returns the result of the actual comparison unless 
comp is a//, in which case the comparison need not be performed at all and equal is 
returned. 
IfCompareSwap: procedure [ 

table: TableHandle, first, second: LongCARDlNAL, comp: CompareOp] 
returns [val: Comparison]; 
Range: procedure [table: TableHandle] 

returns [low: LongCARDlNAL, high: LongCARDlNAL]; 
SubscriptOutOfBounds: ERROR; 

—This procedure allows types to be initialized so the generic procedure can find the 
appropriate specific procedure to call for each type. 
SetTabieTypeArray: PROCEDURE [ 

type: TableType, 

procs: TableProcedures]; 

TableType: type = [stringlnt}; 

—Tables are declared to be a variant record this time so that LOOPHOLES will not be 

necessary. Although there is only one variant, that is only because this toy problem does 
not actually have more than one type of table. The whole point of this exercise is to allow 
several types of tables, so this implementation strategy would not be used unless there 
actually were several different types of tables. 
Table: private type = record [var: 
select type: TableType from 
stringlnt => [ 
size: cardinal, 

t: array [1..1) OF StringlntEntry], 
endcase]; 
StringlntEntry: type = record [name: string, value: integer]; 
TableProcedures: private type = record [ 
IfCompareSwap: procedure [ 

TableHandle, LongCARDlNAL, LongCARDlNAL, CompareOp] 
returns [Comparison], 
Range: procedure [TableHandle] 

returns [LongCARDlNAL, LongCARDlNAL]]; 

StringlntTableProg: program; 
MakeMyTable: procedure [size: cardinal] 
returns [val: pointer to stringlnt Table]; 

CompareOp: type = [0..8); 
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greaterthan: CompareOp = 4; 
equalto: CompareOp = 2; 
lessthan: CompareOp = 1; 
all: CompareOp = 7; 
none: CompareOp = 0; 



END. 



— File: Sort2.mesa Last edited: November 10, 1977 10:13 AM By: Peter Bishop 

DIRECTORY 

DoubleDefs: from "doubledefs", 
SortDefs: from "sortdefs2"; 

SortProg: program imports DoubleDefs 

exports SortDefs 

shares SortDefs = 
begin OPEN DoubleDefs, SortDefs; 

--This sort procedure is written in terms of the IfCompareSwap operation on tables rather than 
the Index and Swap operations on tables and the Compare operation on elements. 

Longl: LongCARDINAL = [highbits:0, lowbits:1] 
Long2: LongCARDINAL = [highbits:0, lowbits:2] 
Long3: LongCARDINAL = [highbits:0, lowbits:3] 

Sort: public procedure [table: TableHandle ] = 
begin 

x,y: LongCARDINAL; 
[x, y] <~ Range [table]; 
SortRange[table, x, y]; 
end; s 

SortRange: procedure [ 

table: TableHandle, i: LongCARDINAL, j: LongCARDINAL] = 

begin 

n, ij, I, k: LongCARDINAL; 

--Sort elements i through j of table to be nondescending. 

— The prefix d means the data at a place in the table. 

--The basic technique is to choose three elements from table 
--at "random" (first, last, middle), sort these three elements, 
—choose the middle element and then divide table into two parts, 
—the part all of whose elements are less than this middle value, 
—and the other part having only elements larger than the middle value. 
--SortRange is then called recursively on these two portions of the table. 

n «- DSub [Dine [j], i]; 

if n.highbits=:0 AND n.lowbits< = 1 then return; —Nothing to sort. 

—Sort i, j. 
[] *~ IfCompareSwap [table, i, j, greaterthan]; 
if n = Long2 then return; --There are only two elements. 

[ij, ] <- DDivide [DAdd [ i, j], Long2]; — ij is the midpoint of t and j. 
--Sort i, ij, j so they are in nondescending order. 

If IfCompareSwap [table, i, ij, greaterthan] >= equal 

then null --We now know that di<=dij<=dj, so they are sorted 

— do nothing. 
else [] *- IfCompareSwap [table, j, ij, lessthan]; -- Now di<=dij<dj. 
if n = Long3 then return; --di, dij, and dj are the only three elements. 
k «- i; 

I «- i; 

—Find k>i and Kj such that dk>dij>dl (i.e. are in reverse order). Swap k and I. 

—Repeat until k and I pass each other, at which point k and I are approximately equal and 
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specify the dividing line in the table between the elements that are less than or equal to 
dij and those that are greater than or equal to dij. SortRange is then called recursively on 
these two portions of the table. 
—Note that elements that are equal to dij are not moved. 

DO 

while IfCompareSwap [ table, l*-DSub [I, Longl], ij, none] #* less 
— No swap was performed, only a comparison. 
do endloop; --Find I such that dKdij. 
while IfCompareSwap [table, (k *- Dine [k]), ij, none] # greater 

DO enqloop; —Find k such that dij<dk. 
if DCompare [k, I] = greater then exit; --Do loop while k<=l. 
[] <- IfCompareSwap [table, k, I, all]; 

--Doesn't compare, just swaps. 
— k will never equal I because dl<dij<dk. 
endloop; 
—Now Kk and di through dl are less than or equal to dij while dk through dj are all greater 
than or equal to dij. 1+1 may be less than k, but only if the elements between dl and dk are 
all equal to dij. Fortunately, all elements equal to dij will cluster at exactly this point in the 
table anyway in one of three ways: 

— 1)l+1<k and the elements between are equal to dij. 

—2) elements equal to dij within di through dl are larger than any other elements in that 

range and so will be placed at I. 
—3) elements equal to dij within dk through dj are less than any other elements in that 
range and so will be placed at k. 
—Thus it is alright for elements equal to dij to be sprinkled all over the table at this point 

SortRange [table, i, I]; 
SortRange [table, k, j]; 

RETURN; 

END; 

SubscriptOutOfBounds: public error = code; 

Range: public procedure [table: TableHandle] 

RETURNS [low: LongCARDINAL, high: LongCARDINAL] = 

BEGIN 

[low, high] *• TableArray[table.type].procs.Range [table]; 
end; 

IfCompareSwap: public procedure [ 

table: TableHandle, first, second: LongCARDINAL, comp: CompareOp] 

returns [val: Comparison] = 

begin 

val «- TableArray[table.type].procs.IfCompareSwap 

[table, first, second, comp]; 
end; 

SetTableTypeArray: public procedure [ 

type:TableType, procs: TableProcedures] = 

BEGIN 

if TableArray [type]. set then error duplicateTypeDefinition []; 
TableArray [type].procs *- procs; 
TableArray [type]. set «- true; 
end; 

TableArray: array TableType of record [ 
set: BOOLEAN, 
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procs: TableProceclures]; 

dupIlcateTypeDefinition: error; 

t: TableType; 

--Initialize the TableArray to all types undefined. Each type can only be defined once. 
for t in TableType do 

TableArray[t].set <- false; 

endloop; 

END. 
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— File: stringinttableprog.mesa Last edited: November 10, 1977 10:05 AM By: Peter Bishop 

DIRECTORY 

SortDefs: from "sortdefs2", 
SystemDefs: from "systemdefs", 
InlineDefs: from "inlinedefs", 
DoubleDefs: from "doubledefs"; 

StringlntTableProg: program imports SortDefs, SystemDefs 

exports SortDefs 

shares SortDefs = 
begin open SortDefs, DoubleDefs; 

—These are the type specific delcarations that were in mytabledefs in Appendix B. 
MyTable:TYPE = stringlnt Table; 
MyTableHandle: TYPE = POINTER TO MyTable; 

MakeMyTable: public procedure [size: cardinal] 
returns [val: MyTableHandle] = 

BEGIN 

val «- SystemDets.AllocateHeapNode[ 

size*siZE[StringlntEntry] + siZE[MyTable]]; 
valt «- [stringlnt [size, ]]; 
end; 

SIRange: private procedure [table: TableHandle] 

returns [tow, high: LongCARDINAL] = 
BEGIN 

with t: table select from 
stringlnt => begin 

low.highbits «- high.highbits <~ 0; 
low.lowbits <- 1; 
high.lowbits *- t.size; 
end; . . 

endcase = > error; 
end; 

Shorten: private procedure [size: cardinal, subscript: LongCARDINAL] 
returns [i: cardinal] = 

BEGIN 

i *- subscript.lowbits; 

if subscript.highbits # or i > size or i = then 

error SubscriptOutOfBounds []; 
end; 

comparray: array Comparison of CompareOp = 
[lessthan, equalto, greaterthan]; 
--this is needed because sets are not supported in Mesa. 

SH f Compares wap: private procedure [ 

table: TableHandle, first, second: LongCARDINAL, comp: CompareOp] 

returns [val: Comparison] = 

BEGIN 

—We see here one of the deficiencies of Mesa: this procedure takes a general TableHandle 
as the first argument even though the generic procedure will never call it with anything but 
MyTableHandle. Fortunately this is not a serious performance question, but is merely an 
annoyance. 
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t: MyTableHandle; 
I, i: cardinal; 

f, s: pointer TO StringlntEntry; 
temp: StringlntEntry; 

with tab: table select from --perform the redundant type check in a way that retains full 

compiler type checking, 
stringlnt => t *- @tab; 

ENDCASE => ERROR; 

f «- @U[Shorten[t.size, first]]; 
s «- @t.t[Shorten[tsize, second]]; 
val «- equal; 
if comp # all THEN 
BEGIN 

I «- MiN[f.name.length, s.name.length]; 
for i IN [0..I) DO 

if f.namejj] # s.name[i] then 
begin 

val «- (if f.name[i] > s.name[i] then greater else less); 
exit; 
end; 
endloop; 
if val = equal then 

if f.name. length > I then val *■ greater 
else if s.name.length > I then val «- less; 
if iniineDefs.BiTAND[comp, comparray[vaI]] = then RETURN; 

—the bitand is needed because Mesa does not support sets, 
--would like to write: if val not in comp then return; 
end; 
temp <- ft; --do the swap, 
ft 4- s t; 
st <- temp; 
end; 

—Initialize the procedure array for this type of table. 
SetTabieTypeArray[type: stringlnt, procs: [SllfCompareSwap, SIRange]]; 

end. 
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~ File: testsort6.mesa Last edited: November 14, 1977 3:07 PM By: Peter Bishop 

DIRECTORY 

lODefs: from "iodefs", 
SystemDefs: from "systemdefs", 
StringDefs: from "stringdefs", 
SortDefs: from H sortdefs6"; 

testsort:PROGRAM 

imports SortDefs, lODefs, SystemDefs, StringDefs 

SHARES SortDefs s 
begin open lODefs, SystemDefs, StringDefs, SortDefs; 

—This implementation has only one type of table and uses only single precision subscripts for 
the table because the representation of the table cannot have more than 65000 entries 
anyway. 

size, i: cardinal; 

p: pointer to StringlntEntry; 

name: string = " "; 

tab: pointer to Table; 

start SortProg; 

start StringintTableProg; 

DO 

WriteString ["Enter size of table: "]; 

size ** ReadDecimal []; 

WriteLine [ ,,M ]; 

tab <- MakeMyTable [size]; 

for i in [L.size] do 

WriteString ["name: "]; 

ReadID [name]; 

p <- @tab.t[i]; 

p.name «- AllocateHeapString[name.length]; 

p.name. length «- 0; 

AppendString[p.name, name]; 

WriteString [" value: "]; 

p.value *- ReadDecimal []; 

WriteLine [""]; 

ENDLOOP; 

—Note that this implementation, like the one that used variant records for tables does not 

require any LOOPHOLES. 
WriteLine ["Sorting"]; 
Sort[tab]; 

for i in [L.size] do 
p *- @tab.t[i]; 
WriteString[p.name]; 
FreeHeapString[p.name]; 
WriteString[" "]; 
WriteDecimal[p.value]; 
WriteLine[""]; 

ENDLOOP; 

FreeHeapNode[tab]; 

stop; 

endloop; 

END. 
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— File: SortDefs6.mesa Last edited: November 14, 1977 1:45 PM By: Peter Bishop 

DIRECTORY 

DoubleDefs: from "doubledefs"; 

SortDefs: definitions = 
begin open DoubleDefs; 

—Note the similarity of this definitions file and sortdefs2.mesa in Appendix C. This definitions 
file does not contain SetTableTypeArray, but that is the major difference. 

SortProg: program; 

TableHandle: type = pointer to Table; 
Sort: procedure [table: TableHandle]; 
IfCompareSwap: procedure [ 

table: TableHandle, first, second: cardinal, comp: CompareOp] 

returns [val: Comparison]; 
Range: procedure [table: TableHandle] 

returns [low: cardinal, high: cardinal]; 
SubscriptOutOfBounds: error; 

Table: private type = record [ 

size: cardinal, t: array [1..1) OF StringlntEntry]; 
StringlntEntry: type = record [name: string, value: integer]; 

StringlntTabteProg: program; 
MakeMyTable: procedure [size: cardinal] 
returns [val: pointer to Table]; 

CompareOp: type = [0..8); 
greaferthan; CompareOp = 4; 
equalto: CompareOp = 2; 
lessthan: CompareOp = 1; 
all: CompareOp = 7; 
none: CompareOp = 0; 

end. 
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— File: Sort6.mesa Last edited: November 14, 1977 2:08 PM By: Peter Bishop 

DIRECTORY 

DoubleDefs: from "doubtedefs", 
SortDefs: from "sortdefs6"; 

SortProg: program imports SortDefs 

EXPORTS SortDefs 

shares SortDefs = 
begin open DoubleDefs, SortDefs; 

—This file is rather different from sort2.mesa in Appendix C because it does not contain 

definitions of the generic procedures since generic procedures are only needed if there are 
many possible implementations of tables. 

Sort: public procedure [table: TableHandle ] = 
begin 

x,y: cardinal; 
[x, y] <- Range [table]; 
SortRange[tabIe, x, y]; 
end; 

SortRange: procedure [ 

table: TableHandle, i: cardinal, j: cardinal] = 

begin 

n, ij, I, k: cardinal; 

—Sort elements i through j of table to be nondescending. 

—The prefix d means the data at a place in the table. 

—The basic technique is to choose three elements from table 
—at "random" (first, last, middle), sort these three elements, 
—choose the middle element and then divide table into two parts, 
—the part all of whose elements are less than this middle value, 
—and the other part having only elements larger than the middle value. 
—SortRange is then called recursively on these two portions of the table. 

n <- j + 1 - i; 

if n<=1 then return; --Nothing to sort. 

—Sort i, j. 
[] «- IfCompareSwap [table, i, j, greaterthan]; 
if n = 2 then return; — There are only two elements. 

U *" + J)/2; ~~ii is the midpoint of i and j. 
—Sort i, ij, j so they are in nondescending order. 

If IfCompareSwap [table, i, ij, greaterthan] >= equal 

then null --We now know that di<=dij<=dj, so they are sorted 

— do nothing. 
else [] *• IfCompareSwap [table, j, ij, lessthan]; — Now di<=dij<dj. 
if n = 3 then return; — di, dij, and dj are the only three elements. 
k «- i; 

I * j; 

—Find k>i and \<\ such that dk>dij>dl (i.e. are in reverse order). Swap k and I. 

—Repeat until k and I pass each other, at which point k and I are approximately equal and 
specify the dividing line in the table between the elements that are less than or equal to 
dij and those that are greater than or equal to dij. SortRange is then called recursively on 
these two portions of the table. 
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--Note that elements that are equal to dij are not moved. 

DO 

while IfCompareSwap [ table, (M-1), ij, none] # less 

--No swap was performed, only a comparison. 
DO endloop; --Find I such that dKdij. 
while IfCompareSwap [table, (k «- k+1), ij, none] # greater 

DO endloop; --Find k such that dij<dk. 
if k > I then exit; —Do loop while k<=l. 
[] <- IfCompareSwap [table, k, I, all]; 

— Doesn't compare, just swaps. 
— k will never equal I because dl<dij<dk. 
endloop; 
—Now \<k and di through dl are less than or equal to dij while dk through dj are all greater 
than or equal to dij. 1+1 may be less than k, but only if the elements between dl and dk are 
all equal to dij. Fortunately, all elements equal to dij will cluster at exactly this point in the 
table anyway in one of three ways: 

— 1)l+1<k and the elements between are equal to dij. 

—2) elements equal to dij within di through dl are larger than any other elements in that 

range and so will be placed at I. 
—3) elements equal to dij within dk through dj are less than any other elements in that 
range and so will be placed at k. 
—Thus it is alright for elements equal to dij to be sprinkled all over the table at this point 

SortRange [table, i, I]; 
SortRange [table, k, j]; 

return; 
end; 

SubscriptOutOfBounds: public error = code; 

end. 
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— File: stringinttabIeprog6.mesa Last edited: November 14, 1977 2:17 PM By: Peter Bishop 

DIRECTORY 

SortDefs: from "sortdefs6", 
SystemDefs: from "systemdefs", 
InlineDefs: from "inlinedefs", 
DoubleDefs: from "doubledefs"; 

StringJntTableProg: program imports SortDefs, SystemDefs 

exports SortDefs 

shares SortDefs = 
begin open SortDefs, DoubleDefs; 

--This file is similar to stringinttableprog.mesa in Appendix C except that use of MyTableHandle 
has been converted to use of TableHandle and there is no initialization code to notify generic 
procedures of the existence of this type of table since there are no generic procedures. The 
type specific procedures are being called directly now. 

MakeMyTable: public procedure [size: cardinal] 
returns [val: TableHandle] = 

BEGIN 

val «- SystemDefs.AllocateHeapNode[ 

size*siZE[StringlntEntry] + siZE[Table]]; 
vatt <- [size, ]; 

end; 

Range: public procedure [table: TableHandle] 
returns [low, high: cardinal] = 

BEGIN 

low <- 1; 

high <- table.size; 

end; 

'Shorten: private procedure [size: cardinal, subscript: cardinal] 
returns [i: cardinal] = 

BEGIN 

if subscript > size or subscript = then 

error SubscriptOutOfBounds []; 
i «- subscript; 
end; 

comparray: array Comparison of CompareOp = 
[lessthan, equalto, greaterthan]; 

IfCompareSwap: public procedure [ 

table: TableHandle, first, second: cardinal, comp: CompareOp] 
returns [val: Comparison] = 

BEGIN 

t: TableHandle; 

I, i: cardinal; 

f, s: pointer to StringlntEntry; 

temp: StringlntEntry; 

t <- table; — this is the easiest way to change the general code. 

f <- @t.t[Shorten[t.size, first]]: 

s *- @t.t[Shorten[t.size, second]]; 

val <- equal; 

if comp # all then 

BEGIN 

I «- MiN[f.name.length, s.name.length]; 
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FOR i IN [0..I) DO 

if f.name[i] # s.namejj] then 

BEGIN 

val «- (if f.name[i] > s.name[i] then greater else less); 

exit; 

end; 
endloop; 
if val = equal then 

if f.name.length > I then val <- greater 
else if, s.nameJength > I then val «- less; ' 

IF lnlineDefs.BITAND[comp, COmparray[val]] = THEN RETURN; 

end; 
temp «- ft; 
ft *- st; 
st *- temp; 
end; 



END. 



